PCT/GBOO/03689 

B;^ENT COOPERATION TRE/f^ 



From the INTERNATIONAL BUREAU 



PCT 


To: 




Commissioner 


NOTIFICATION OF ELECTION 


Uo ueparimsni ot Lrommerce 


United States Patent and Trademark 


(PCT Rule 61.2) 


Office, PCT 


2011 South Clark Place Room 








Arlington, VA 22202 


Date of mailing (day/month/year) 


ETATS-UNIS D'AMERIQUE 


05 June 2001 (05.06.01) 


in lis Coipoiciiy ab eieuicu v/mue 


International application No. 


Applicant's or agent* s file reference 


PCT/GBOO/03689 


30990134 WO 


International filing date (day/month/year) 


Priority date (day/month/year) 


25 September 2000 (25.09.00) 


25 September 1999 (25.09.99) 


Applicant 




PEARSON, Siani et a! 




1. The designated Office is hereby notified of its election made: 


in the demand filed with the International Preliminary Examining Authority on: 


11 April 2001 (11.04.01) 


1 1 in a notice effecting later election filed with the International Bureau on: 


2. The election ^] was 




1 1 was not 




made before the expiration of 19 months from the priority date or, where Rule 32 applies, within the time limit under 


Rule 32.2(b). 






Authorized officer 


The International Bureau of WlPO 


Zakaria EL KHODARY 


34« chemin des Colombettes 


121 1 Geneva 20, Switzeriand 




Facsimile No.: (41-22) 740.14,35 


Telephone No.: (41-22) 338.83.38 



^ ^ EL652175896US 
The demand must be filed direafy with the competent Intematkml Preliminary Examining Authority or. if two or more Authorities are competent, 
vrith the one chosen by tte applicant. Th^jjLname or two-letter code of that Authority may be j/^ged by the apidicant on the Urn be/oiv: 
IPF A/ EP 



PCX 

DEMAND 

under Article 31 of the Patent Cooperation Treaty: 
The undersigned requests that the international apphcation specified below be the subject of 
international preliminary examination according to the Patent Cooperation Treaty and 
herd>y elects all eligible States (except where otherwise indicated). 



CHAPTER II 



^ Identification of IPE A 


Date of receipt of DEMAND | 


Box No. I IDENTIFICATION OF THE INTERNATIONAL APPUC ATION 


Applicant's or agent's file reference 


International application No. 
PCT/GBOO/03689 


International filing date (day/month/year) 
25/D9/2000 


(Earliest) Priority date (day/month/year) 
25/09/1999 



TRUSTED COMPUTING PLATFORM FOR RESTRICTING USE OF DATA 



Box No. n APPUCANTCS) 



Name and address: ^amUvnamefoBowed by given name: for a legal entity, lull (^cial desSgpation. 
The address must inidhide postal code and name afoountiyj 

Hewlett-Packard Company 
Incorporated in the State of Delaware 
3000 Hanover Street 
Palo Alto, CA 94304 
USA 


Telephone No.: 


Facsinule No.: 


Teleprinter No.: 


State (diat Is, country) of nationality: 
USA 


State (diat is, country) of residence: 
USA 



Name and address: ff^anOfy name Mowed txygfvm name: fen- a legal entity. Ml Mdaldesiffiation. The address must incbide postal code and name of country.) 

PEARSON, Slani 
35 Sandyleaze 
Westbury-on-Trym 
Bristol BS9 3PZ 
GB 



State (that Is. country) of nationality: 


State (that is. country of residence: 


GB 


GB 



Name and address: (Family name Mmved by gi)^ name: for a legal entity, lull official designadon. The address must include postal code and name of counayj 



CHEN, Liqun 
1 Harvest Close 
Bradldy Stoke 
Bristol BS32 9DQ 
GB 



State (that is, country) of nationality: 
CN 



State (that is, country) of residence: 
GB 



[ I Further applicants are indicated on a continuation sheet. 



Form PCT/IPEA/40 1 (first sheet) (July 1 998; reprint July 1 999) 



See Notes to the demand form 



Sheet No.^. 



ational apph'cation No. 
PCT/GBOO/03689 



Box No. m AGENT OR COMMON REPRESENTATIVE; OR ADDRESS FOR CORRESPONDENCE 



The following person is \ )(\ agent | | common representative 

and |)iC I has been appointed earlier and represents the appl!cant(s) also for international preliminary examination. 

I I is hereby appointed and any earlier appointment of (an) agent(s)/conmion rq>resentative is hereby revoked. 

I I is hereby appointed, specifically for the procedure before the International Preliminary Examining Authority, in addition to 
— the agent(s)/common representative appointed earlier. 



Name and address: SsofUly name followed gfven name: for a legal entity, fvU official desJgnaUan. 
The sadress must include postal code and name of countiy.) 

LAWRENCE, Richard Anthony 

Mewtett-Packard Limited 

Intellectual Property Section 

Fiiton Road 

Stoke Gifford 

Bristol BS34 8QZ 

GB 



Telephone No.: 

(0) 117-312-8295 



Facsimile No.: 

(0)117-312-8941 



Teleprinter No.: 



□ Address for correspondence: Mark this check-box where no agent or common representative is/has been appointed and the 
space d)ove is used instead to indicate a special address to wtiich correspondence should be sent 



Bm No.IV BASIS FORINTERNATIONALPRELIMINARYI^CAMINATION 



Stateminit concerafaig amendments:* 

1 . The applicant wishes the international preliminary examination to start on the basis of: 
\[iC\ die international application as originally filed 

the description I I as originally filed 

I I as amended mider Article 34 

the claims | | as originally filed 

I I as amended under Article 1 9 (together with any accompanying statement) 
I I as amended under Article 34 

the drawings | ) as originally filed 

1 1 as amended under Article 34 

2. I I The applicant wishes any amendment to the claims under Article 1 9 to be considered as reversed. 

3. I I The applicant wishes the start of the international preliminaiy examination to be postponed until the expiration of 20 months 

from the priority date unless the International Preliminary Examining Authority receives a copy of any amendments made 
under Article 1 9 or a notice from the applicant that he does not wish to make such amendments (Rule 69. 1 (d)). (This check- 
box may be marked only where the time limit under Article 19 has not yet expired.) 

♦ Where no check-box is marked, international preliminary examination will start on the basis of the international application 
as originally filed or, where a copy of amendments to the claims under Article 1 9 and/or amendments of the international application 
under Article 34 arc received by the International Preliminary Examining Authority before it has begun to draw up a written opinion 
or the international preliminary examination report, as so amended. 



Language for the purposes of international preliminary examination: .Engjjsh 

(y 1 which is the language in which the international application was filed. 

I- - I which is the language of a translation furnished for the purposes of international search. 

I I which is the language of publication of the international application. 

{ I which is the language of the translation (to be) furnished for the purposes of international preliminary examination. 



Box No. V ELECTION OF STATES 



The applicant hereby elects all eligible States (tfiat is, all States which have been designated and which arc bound by Chapter 11 of 
the pen 

excluding the following States which the applicant wishes not to elect: 



Form PCT/IPEA/401 (second sheet) (July 1998; reprint July 1999) 



See Notes to the demand form 



Sheet No. ?. . 



J__ 



lational application No. 
PCT/GBOO/03689 



Box No. VI CHECKLIST 



The demand is accompanied by the following elements, in the language referred to in 
Box No. IV, for the puiposes of international preliminary examination: 







received 


not received 


1. translation of international appiication 


sheets 


L-JI 


l_l 


2. amendments under Article 34 


sheets 


□ 


□ 


3. copy (or, where required, translation) of 
amendments under Article 1 9 


sheets 


□ 


□ 


4. copy (or, where required, translation) of 
statement under Article 1 9 


sheets 


□ 




5. letter 


sheets 


D 


□ 


6. other (specify) 


sheets 


O 


□ 



For International Preliminary 
Examining Authority use only 



The demand is also accompam'ed by the item(s) marked below: 

1. |X| fee calculation sheet 

2. I I separate signed power of attorney 

3. I I copy of general power of att<Mney; 
— reference number, if any: 



4. \ I statement explaining lack of signature 

5. I I nucleotide and or amino acid sequence 

computer readable fom 

6. I I odier (specify): 



in 



BoxNo.Vn SIGNATURE OF APPUCANT* AGENT OR COMMON REPRESENTATIVE 



) 



Neato€adisigimjie,iiKtcatBaieaanieaAepasonsi^^ 





Richard Anthony Lawrence 
Senior Intellectual Property Attorney 



For International Preliminary Examining Authority use only 



1 . Date of actual receipt of DEMAND: 



2. Adjusted date of receipt of demand due 
to CORRECTIONS under Rule 60. 1 (b): 



3 j I The date ofrcceiptofthe demand is AFTER the expiration of 19 months | — i Theappli 
I — I from the priority date and item 4 or 5, below, docs not apply. I — I informed 



ilicant has been 
[ accordingly. 



4. 1 I Thf date of receipt of the demand is WITHIN the period of 19 months from the priority date as extended by virtue of 
■ i.. .1 Rule oO.S. 



5. |~l Although the date of receipt of the demand is after the expiration of 19 months from the priority date, the delay in arrival 
I — I is EXCUSED pursuant to Rule 82. r j » j 



For International Bureau use only 



Demand received from IPSA on: 



Form PCT/lPEA/401 (last sheet) (July 1998; reprint July 1999) 



See Notes to the demand form 



i 

EL652175896US 

^TENT COOPERATION TRIj^Y 

PCT 



INTERNATIONAL PRELIMINARY EXAMINATION REPORT 

(PCT Article 36 and Rule 70) 



Applicant's or agent* s file reference 
30990134 WO 


See Notification of Transmittal of International 
FOR FURTHER ACTION Preliminary Examination Report (Fomi PCT/IPEA/416) 


International application No. 
PCT/GBOO/03689 


International filing data (day/month/year) 
25/09/2000 


Priority date (day/monWyear) 
25/09/1999 


International Patent Classification (IPC) or national classification and IPC 
G06F1/00 


Applicant 

HEWLETT-PACKARD COMPANY et al. 



1 . This international preliminary exannination report lias been prepared by this International Preliminary Examining Authority 
and is transmitted to the applicant according to Article 36. 



2. This REPORT consists of a total of 5 sheets, including this cover sheet. 

H This report is also accompanied by ANNEXES, i.e. sheets of the description, claims and/or drawings which have 
been amended and are the basis for this report and/or sheets containing rectifications made before this Authority 
(see Rule 70.16 and Section 607 of the Administrative Instructions under the PCT). 

These annexes consist of a total of 9 sheets. 



3. This report contains indications relating to the following Items: 



1 


IS 


Basis of the report 


11 


□ 


Priority 


III 




Non-establishment of opinion with regard to novelty, inventive step and industrial applicability 


IV 


□ 


Lack of unity of invention 


V 


□ 


Reasoned statement under Article 35(2) with regard to novelty. Inventive step or industrial applicability; 
citations and explanations suporting such statement 


VI 


□ 


Certain documents cited 


VII 


□ 


Certain defects in the international application 


VIII 




Certain observations on the international application 



Date of submission of the demand 
11/04/2001 


Date of completion of this report 
24.01.2002 


Name and mailing address of the international 
preliminary examining authority: 
- - ' * ^ European Patent Office 
/^jl D-80298 Munich 
_ iSy' Tel. +49 89 2399 - 0 Tx: 523656 epmu d 
Fax: +49 89 2399 - 4465 


Authorized officer ^^-s^sr^ 
Meis. M (l ^ )) 

Telephone No. +49 89 2399 2505 ^^^.^^^j^ 



Form PCT/IPEA/409 (cover sheet) (January 1994) 



INTERNATIONAL PRELIMINARY 
EXAMINATION REPORT 



International application No. PCT/GBOO/03689 



I. Basis of the report 

1 . With regard to the elements of the international application (Replacement sheets which have been furnished to 
the receiving Office in response to an invitation under Article 14 are referred to in this report as "originally filed" 
and are not annexed to this report since they do not contain amendments (Rules 70, 16 and 70. 1 7)): 
Description, pages: 

1 -41 as originally filed 

Claims, No.: 

1 -24 as originally filed 

Drawings, sheets: 

1/9-9/9 as received on 03/1 1/2000 

2. With regard to the language, ail the elements marked above were available or fumished to this Authority in the 
language in which the international application was filed, unless otherwise indicated under this item. 

These elements were available or fumished to this Authority in the following language: , which is: 

□ the language of a translation furnished for the purposes of the international search (under Rule 23.1 (b)). 

□ the language of publication of the international application (under Rule 48.3(b)). 

□ the language of a translation fumished for the purposes of international preliminary examination (under Rule 
55.2 and/or 55.3). 

3. With regard to any nucleotide and/or amino acid sequence disclosed in the international application, the 
international preliminary examination was carried out on the basis of the sequence listing: 

□ contained in the international application In written form. 

□ filed together with the international application in computer readable form. 

□ furnished subsequently to this Authority in written form. 

□ fumished subsequently to this Authority in computer readable form. 

□ The statement that the subsequently furnished written sequence listing does not go beyond the disclosure in 
the international application as filed has been furnished. 

□ The statement that the Information recorded in computer readable form is identical to the written sequence 
listing has been furnished. 

4. The amendments have resulted in the cancellation of: 

□ the description, pages: 

□ the claims, Nos.: 



Form PCT/IPEA/409 (Boxes l-VIII. Sheet 1) (July 1998) 



INTERNATIONAL PRELIMINARY 
EXAMINATION REPORT 



International application No. PCT/G BOO/03689 



□ the drawings, sheets: 

5. □ This report has been established as if (some of) the amendments had not been made, since they have been 

considered to go beyond the disclosure as filed (Rule 70.2(c)): 

(Any replacement sheet containing such amendments must be referred to under item 1 and annexed to this 
report.) 

6. Additional observations, if necessary: 



111. Ndn-establishrneht of dpiiiion with regdrd to novelty, inventive step and industrial applicabinty 

1 . The questions whether the claimed invention appears to be novel, to Involve an inventive step (to be non- 
obvious), or to be industrially applicable have not been examined in respect of: 

□ the entire international application. 
El claims Nos. 1-24. 

because: 

□ the said international application, or the said claims Nos. relate to the following subject matter which does 
" not require an intemational preliminary examination (specif)^: 



□ the description, claims or drawings {indicate particular elements belov\^ or said claims Nos. are so unclear 
that no meaningful opinion could be formed (specify^: 



El the claims, or said claims Nos. 1-24 are so inadequately supported by the description that no meaningful 
opinion could be formed. 

□ no international search report has been established for the said claims Nos. . 

2. A meaningful intemational preliminary examination cannot be carried out due to the failure of the nucleotide 
and/or amino acid sequence listing to comply with the standard provided for in Annex C of the Administrative 
Instructions: 

□ the written form has not been furnished or does not comply with the standard. 

□ the computer readable form has not been furnished or does not comply with the standard. 

Vlii. Certain observations on the international application 

The following observations on the clarity of the claims, description, and drawings or on the question whether the 
claims are fully supported by the description, are made: 
see separate sheet 



Form PCT/tPEA/409 (Boxes l-Vtll. Sheet 2) (July 1998) 



INTERNATIONAL PRELIMINARY International application No, PCT/G BOO/03689 

EXAMINATION REPORT - SEPARATE SHEET 



SECTION ill 

1. Claims 1 - 24 are not supported by the description as required by Article 6 PCT, 
as their scope is broader than justified by the description and drawings. The rea- 
sons therefor are the following: 

CI. 1 and 14 require a client platform to be adapted such that data received is 
used for display of the data and not for an unauthorised purpose. 

This is a strong requirement for which no reliable means have been found yet to 
fulfill it. Text, image or video data displayed on the client platform may be 
obtained by frame grabbing from client platform video or (Internal or extemal) 
display connectors or by photographing or filming the display. Though the data is 
to be used for display only, the data thus obtained can printed, copied or 
transmitted in any way, allowing any possible use, including unauthorized ones. 

CI. 11, 14 and 18 require a server adapted to determine that a client platform is 
adapted to ensure restricted use of data. 

A server remotely installed from a client is aware of the client via communication 
messages via communication links only. 

Actually is no known way the server can ensure reliably that the client it is 
communicating with indeed is the client it intends to communicate with. A fake 
client might properly communicate in the way expected by the server without the 
server being aware thereof. The fake client may give full access for any use to the 
data it receives from the server. 

In addition, assuming the server communicating with the client it expects to 
communicate with, it has no more ways of determining use of data at the client 
platform other than an intended restricted use - see above. 

These aspects of the invention as claimed are not covered by the description, 
hence giving rise to the present objection. 



Form PCT/Separate Sheet/409 (Sheet 1) (EPO-April 1997) 



INTERNATIONAL PRELIMINARY Intemationai application No. PCT/G BOO/03689 

EXAMINATION REPORT - SEPARATE SHEET 



Since dependent cl. 2 - 10, 12 - 13, 15 - 17 and 19 - 24 do not restrict the scope of 
independent cl. 1 , 11, 14 and 18 they respectively depend on as regards the 
above matters regarding restricted use of data, the objection of lack of support in 
the description also applies to the dependent claims. 

SECTION VIII 

1 . The features of the claims are not provided with reference signs placed in 
parentheses (Rule 6.2(b) PCT). 
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REQUEST 



The undersigned requests that the present 

international application be processed 
according to the Patent Cooperation Treaty. 



10/088?I>8 

1 For receiving Office use only 



International Application No, 



Intcmational Filing Date 



Name of recei ving Omce and "PCX International Application" 



IAfSilicant*s or agent's file reference 
(if desired} (U <Aaracters maximum) 30990134 WO 



Box No. I TITLE OF INVENTION 
Trusted Terminal 



Box No. n APPLICANT 



Name 

desigrii 

address indicatedin. this BoxisUte appi 
of residence is indicated below.) 

Hewlett-Packard Company 
3000 Hanover Street 
Palo Alto 
CA 94304 
US 



entity, fall official 



j [ This person is also inventor. 



Telephone No. 



Facsimile No. 



Telqirinter No. 



state (diat is, eomby) of nationality: 
US 


State (lhat ia. country) of 
US 


residence: 




Box No. ra FURTHER APPLICANT(S) AND/OR (FURTHER) INVENTOR(S) 





Name and address: 

designation. Tlie au^^^- 

ad^^ indicated in this Box ts the appi 
qfresidefu:e is indicated below.) 

PE>iaRSON. Siani 
35 Sandyteaze 
Westbury-on-Trym 
BRISTOL BS9 3PZ 
GB 



This person is: 

I I applicant only 

I applicant and inventor 

□ inventor only this check-box 
is marked, do not fill in belo\f.) 



State (that is, country) of nationality: 
GB 



State (that is, country) of residence: 
GB 



This person is applicant 
for the purposes of: 



□ all desigpated I 1 all designated SUtes exce^ 
States I I the United States of Amcnca 



Sthe United States 
of America only 



□ the States indicated in 
the Supplemental Box 



Further applicants and/or (further) inventors are indicated on a continuation sheet. 



Box No. IV AGENT OR COMMO N REPRBSENTATIVB; OR ADDRESS FOR CORRESPONDENCB ^ 

[ agent | | common representative 
Telephone No. 



The person identified below is hereby/has been appointed to act on behalf 
of the applicant(s) before the competent International AuthoriUes as: 



Name and address: (Family namejollowed by given nante; for a ^fS^^ J^^'Ml^^^i 
"™ designation. The address must inchide postal code and name of counSry.) 

LAWRENCE. Richard Anthony 

Hewlett-Packard Limited 

Intellectual Property Section 

Filton Road 

Stoke Gifford 

BRISTOL BS34 8QZ GB 



+ 44(0) 117 312 8295 



Facsimile No. 

+ 44(0)117 312 8941 



Teleprinter No. 



Address for correspondence: Mark this check-box where no asent or common representative is/has been appointed and the 

space above is used instead to indicate a special address to which correspo ndence should be sent. 

Form PCT/RO/101 (first sheet) (July 1998; reprint July 2000) " See Notes to the request form 



Sheet No. 



Continuation of Box No. IH FURTHER APPLICANT(S) AND/OR (FURTHER) INVENTOR(S) 


If none of the following sub-boxes is used, this sheet should not be included in the request 


Name and address: (Fatnify name followed by givett name; for a legal entity, full official 
designation. Vie address must include postal code mid nanie of counJ^, Thecmmtryoflhe 
adc^ess indicated in this Box is die applicant 's State (thai is, country) of residence ffnoState 
ofresidence is indicated below.) 
el4tN. LIqun 

1 Harvest Close 

Bradley Stoke 

BRISTOL BS32 9DQ 

GB 


This person is: 

1 1 applicant only 

\)C 1 applicant and inventor 

1 1 inventor only (Ifdiis check-box 
* it marked, do not fill in below.) 


State (Aatis, country) of nationdity. 
CN 


State (that is, country) of residence: 
GB 


This person is applicant l 1 all designated 1 1 all designated States except fOT die United States 1 1 Ac States indicated in 

for the purposes of: 1 1 States LJ the United States of America IflLl of Amenca only | | the Supplemental Box 


Name and address: (Family name followed by given name; for a legal entity, fidl official 
designation. The address must tncJudepostalcode and name of counoy. Thecotmbryofihe 
- ddiSess iruUcated in diis Box is the appucant 's State. (that is, count>y).of residence ifnootate 
of residence is indicated below.) 


This person is: 

1 1 applicant only 

{ 1 applicant and inventor 

1 1 inventor only ((f this check-box 
*— * is marked, do not fill in below.) 


State (Aat is, country) of nationality: 


State (that is, country) of residence: 


This person is applicant ( 1 aU designated 1 — 1 all designated Statra exc<^ 1 — | the United Statoi 1 1 &e Statej in&c«acdin 
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5 Field of Invention 

The invention relates to provision of trusted terminal functionality in a client/server 
system. The invention is relevant to provision of content to a user, or trialling of 
software by a user, without risk to the content or software owner that the content or 
10 software will be misused. 

Description of Prior Art 

In this specification, *data' signifies anything that can be formatted digitally, such as 
15 images, software and streaming media. 

In the future, computer systems will be able to achieve a more secure booting, 
together with integrity checks on other code to ensure that viruses or other 
unauthorised modifications have not been made to the operating systems and mounted 
20 software. In addition, a new generation of tamper-proof devices are already appearing 
or will soon appear on the market and include both external or portable modules (such 
as smart cards) and internal modules (embedded processors, semi-embedded 
processors or co-processors with security functionality, i.e. including motherboard, 
USB (Universal Serial Bus) and ISA (Industry Standard Architecture) 
25 implementations). These tamper-proof modules will be used to check that the 
hardware of the system has not been tampered with, and to provide a more reliable 
form of machine identity than currently available (for example, the Ethernet name). 
Despite this, counteraction of data piracy, and hcensing and metering use of software 
in a manner that is acceptable to both software developers and end-users is still a 
30 significant problem. 

Software hcensing is subject to hackers and piracy, and all the current software 
licensing methods used have problems associated with them. Software 



wo 01/23980 




PCT/GBOO/03689 



2 

implementations of licensing (such as "licence management systems") are flexible, 
but not especially secure or fast. In particular, they suffer from a lack of security (for 
example, being subject to a generic "hack") and difficulty in genuine replacement of 
software. Conversely, hardware implementations ("dongles") are faster and generally 
5 more secui-e than software implementations, but inflexible. They are tailored only for 
a particular piece of software and are inconvenient for end-users. 

Prior art in the field of content protection includes techniques such as watermarking of 
content, software wrappers around content, protecting passwords and fingerprinting 

10 techniques. In addition, there are various approaches that involve encryption of 
content that is sent to the client machine, and a decryption key being sent to the client 
machine in order that it can decrypt the content. All these approaches suffer from the 
potential drawback that the client machine could be untrustworthy, and that the data 
could be abused once decrypted or otherwise made available to the client machine (for 

15 example, by the protection mechanism being hacked, or by the clear version being 
copied). 

Summary of the Invention 

20 In a first aspect of the invention, there is provided a client platform adapted to provide 
restricted use of data provided by a server, the client platform comprising: a display; 
secure communications means; and a memory containing image receiving code for 
receiving data from a server by the secure communication means and for display of 
such data; wherein the client platform is adapted such that the data received from a 

25 server is used for display of the data and not for an unauthorised purpose. 

In a second aspect of the invention there is provided a server adapted to provide data 
to a client platform for restricted use by the client platform, comprising: a memory 
containing image sending code for providing an image of data executed on the server; 
30 and secure communications means for secure communication of images of data to a 
client platform, whereby the server is adapted to determine that a cHent platform is 
adapted to ensure restricted use of the data before it is sent by the image sending code. 
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In a third aspect the invention provides a system for providing image data securely to 
a user for restricted use, comprising a cUent platform as described above and a server 
as described above, wherein a user on the client platform requests image data from the 
server to view at the client platform. 

5 

In a fourth aspect the invention provides a method of providing image data to a client 
platform for restricted use, comprising a client platform requesting image data from a 
server, the server determining that the client platform both has permission to receive 
image data, and is adapted to use the image data only for the restricted use, and 
10 provision of the image data over a secure communication channel. 

Preferred embodiments of the invention provide enforced trusted terminal 
functionality in a full function platform - this enables the display of data processed 
remotely, while preventing the misuse of that data. Benefits can be obtained for 
client, server, or developer, as the system can be used for a wide range of services, 
including protection of private information, licensing of data, or allowing trial 
software to have fiiU fiinctionality without risk of copying or misuse. These benefits 
arise because the chent platform can be trusted to output data faithfully, in such a way 
that the data itself cannot be copied or modified. Hence, for example, full 
functionality can be used for trial software, which is rarely the case at present because 
of the security risks involved. Advantages are also present for end users - one is that 
sensitive information such as e-mail messages need not be stored on the hard disk of 
the client machine, so in hot-desking situations (such as use of a shared terminal in a 
public place) such information can be effectively protected against attacks on its 
confidentiality or integrity. 

The approach in embodiments of the present invention to conent protection differs 
from existing prior art models: here, at least part of the information is generally 
temporarily stored in protected memory either within, or only accessible by, tamper- 
30 resistant hardware before deletion, and this part is not stored on the hard disk. The 
tamper-resistant hardware is used for authentication, for controlling the output of the 
image and optionally for billing. The client machine never gets the whole data 
package (protected or unprotected), as it does in conventional models described, and 



20 
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so it is not possible to abuse the software via the client machine in ways to which 
prior art approaches are susceptible. Hence, for example, the user will be able to copy 
the screen or retype text from the screen, but will not be able to copy an original 
document; in the case of music, the user will be able to listen to a soundtrack and 
5 record the sound in the room, but will not be able to copy the digital object directly. 
This cuts down the attractiveness of piracy considerably. 

In addition to the benefits of protection against copying and unauthorised use of data, 
and increased flexibility in licensing models such as pay-per-use and time-dependent 

10 models, embodiments of the invention offer protection against hacking attempts such 
as modification or deletion of data wrappers stored on the client platform, since such 
storage never takes place in this model and tamper-resistant hardware within the client 
platform protects against alteration of any image within the platform. More 
specifically, if data access is allowed to users on a trial basis, at present the danger of 

15 copying or modification of the usage controls upon such data is generally considered 
too large to allow anything but an inferior product to be sent for trial usage. Systems 
provided by embodiments of the present invention allow software with fiill 
functionality, or images with full resolution, to be examined by end-users. 

20 Although systems according to embodiments of the present invention can be used for 
the purposes of software licensing, or provision of fiill functionality trial software as 
mentioned above, they can be used instead or in conjunction with these in order to 
also protect private information of the client. For example, if an end-user logs in to a 
shared terminal containing tamper-resistant hardware in order to access private 

25 information, possibly using remote login, then this information is only stored in 
protected memory either within or accessible only via the hardware and not on the 
hard disk, and can be deleted entirely after the user has logged out. 

In preferred embodiments of the invention, client platform (and server) employ a 
30 tamper-proof component, or "trusted module" in conjunction with software, 
preferably running within the tamper-proof component, that controls manipulation of 
and selections relating to a data image to be transferred between the such computer 
platforms. The trusted module or modules have a significant role in ensuring that 
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trusted terminal functionality is provided in a full function platform. Metering records 
can be stored in a tamper-proof device or smart card and reported back to 
administrators as required. There can be an associated clearinghouse mechanism to 
enable registration and payment for data. 

The tmsted module or component is preferably immune to unauthorised modification 
or inspection of intemal data. It is physical to prevent forgery, tamper-resistant to 
prevent counterfeiting, and preferably has cryptographic functions to securely 
communicate at a distance. Methods of building trusted modules are, per se, well 
known to those skilled in the art. The trusted module may use cryptographic methods 
to give itself a cryptographic identity and to provide authenticity, integrity, 
confidentiality, guard against replay attacks, make digital signatures, and use digital 
certificates as required. These and other cryptographic methods and their initiahsation 
are well known to those skilled in the art of security. 

In a particularly preferred arrangement, a licensing system employing embodiments of 
the present invention comprises at least two computer platforms, one acting as server 
and one as client, which are connected by a secure communications path. Each 
computer platform has: a trusted module which is resistant to intemal tampering and 
which stores a third party's pubUc key certificate; means of storing remote imaging 
code (in the case of the server, remote image sending code for providing an interface 
for sending information fi-om the server to other trusted platforms corresponding to an 
image of data executing upon the server; in the case of the client, remote image 
receiving code for providing an interface for receiving information fi"om other trusted 
platforms corresponding to an image of data which may be displayed upon the 
monitor of the chent platform and/or capturing user selections relating to the running 
of such an image and relaying these back to the server platform); and means of storing 
a hashed version of the remote imaging code signed with the third party's private key; 
wherein the computer platform is programmed so that, upon booting of the platform, 
the remote imaging code is integrity checked with reference to the signed version and 
the public key certificate, and if the integrity check fails, the remote imaging code is 
prevented fi-om being loaded. If the integrity check fails, it may be arranged that the 
complete platform integrity fails. Optionally, part of the functionality of the remote 
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imaging code may be carried out by hardware within the local trusted component 
rather than by software. One or more smart cards, with an associated reader, are an 
additional, optional part of the computer platform - the smart cards may provide user 
(rather than platform) licenses to allow access to the image data. 

5 

It is possible for trusted terminal functionality to be employed in a number of different 
ways. The extreme form of the general model is that licensed data is executed on the 
server, and not on the client. In return for payment, the client receives imaging 
information corresponding to the execution of the data on the tmsted server. This is 

10 sent via the remote image sending code on the server. Thereafter, the remote image 
receiving code on the client machine sends to the server keyboard strokes, 
corresponding to the selections of the user, and receives in return imaging 
information, corresponding to the changing execution of the application. The imaging 
information is sent directly from the trusted server via a secure channel such as PPTP 

15 to the tmsted component within the client, which is adapted to display the imaging 
information directly without having to involve any untmsted parts of the computing 
apparatus. 

There are other possibilities available as regards how much software actually runs on 
20 the client. It is not efficient in all cases to run all software on the server rather than the 
client. For relatively sensitive information (this might apply for data access, or where 
there may be substantial overlap each time the software runs) it might be apphcable to 
store temporarily all of the image in client protected memory, and have the software 
displayed on the client, but actually running on the server. The client at no stage stores 
25 the software apart from the image stored in the protected memory, and therefore is not 
liable to licence infringement attacks on the data via the hard disk or other storage 
media. For less sensitive information, and especially where an application may 
produce differing images each time it is run, as is usually the case with game 
software, it would probably be more appropriate to run the software only partly from 
30 the server; for example, essentially mnning locally, but needing certain critical input 
from the server (such as an on-line service) in order to run the software. The server 
must still have overall control, so that although the client machine may be able to mn 
the program, the run cannot succeed without the server being involved. There are 
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different ways of carrying this out: for example, the server could supply key bits of 
the information, and transmit the image in communal blocks which would be the same 
for all clients, with the chent trusted component repeatedly authenticating to the 
server trusted component for personalised information or key bits; or some of the data 
5 could be stored locally, with the server transmitting additional data to the protected 
memory. For the sake of efficiency, during and after execution, only part of the 
information (such as the key bits) is stored in the protected memory, and the rest can 
be stored on the hard disk or other storage media. This partial model of image transfer 
can be used concurrently with total models for different data on the same server 

10 

The server is in a tmsted environment, which is protected against data and wrappers 
being altered or copied. Hence, licensing models such as pay-per-use and time- 
dependent models, as well as more traditional models, may be used in a secure 
manner. 

15 

Preferably display processing is controlled from within the tmsted component so that 
the display to the user cannot be subverted, hi cases where a user smart card is 
required to obtain the image data, a seal image can be displayed on the client display 
which only the owner of the smart card inserted into the reader knows to be their 

20 correct seal image, in order to check the security of the connection between the client 
and server. Before the smart card owner carries out sensitive tasks such as providing 
billing information, the smart card may require authentication from the trusted 
component of the client platform (this authentication may be enhanced by the seal 
image being shown on the client monitor) and so require authorisation from the smart 

25 card owner before any sensitive information is conveyed. 

As an option, the display of a selected area of pixels on the trusted client platform 
may be reserved for an alternative usage by the server tmsted platform, perhaps on 
behalf of a third party. The given pixel area can vary over time, and convey 
30 information that may not directly be related to the data executing on the trusted server 
platform. This allows adverts or other proprietary information to be incorporated into 
the display image sent by the server trasted platform, or a tmsted third party. 



Brief Description of Drawings 
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Figure 1 shows elements of a host computer appropriate for use as a trusted client 
platform in embodiments of the invention; 

5 Figure 2 shows the hardware architecture of the host computer of Figure 1 ; 

Figure 3 shows the elements of a trusted device suitable for use in embodiments of the 
invention; 

10 Figure 4 shows a preferred process for obtaining an integrity metric; 

Figure 5 shows a process for verifying the integrity of a trusted platform; 

Figure 6 shows a process for verifying the integrity of a trusted platform by a user 
15 with a smart card; 

Figure 7 shows the processing engine of a user smart card suitable for use in the 
process of Figure 6; 

20 Figure 8 shows a modification to the arrangement of Figure 2 to provide trusted 
communication paths between the trusted device and other components of the host 
computer; 

Figure 9 shows a process by which incoming messages are decrypted in the 
25 arrangement of Figure 8 when the trasted device is the only component of the host 
computer with cryptographic capabilities; 

Figure 10 shows the basic elements of a client/server system according to an 
embodiment of the invention; and 

30 

Figure 1 1 shows a process for trusted terminal operation of the client/server system of 
Figure 10 according to an embodiment of the invention. 



• 



wo 01/23980 ^ — PCT/GBOO/03689 

9 

Description of Preferred Embodiment 



An embodiment of the present invention will now be described, by way of example. 
A part of the system of this preferred embodiment is a client platform will be 

5 described which contains a trusted component, the trusted component allowing secure 
and reliable interaction with the chent platform by users or other parties 
communicating with the client platform. Such a trusted component is described 
below, but is more fully described in the applicant's copending International Patent 
Application No. PCT/GB 00/00528 entitled "Trusted Computing Platform" filed on 

10 15 February 2000 and incorporated by reference herein. The trusted component in the 
cUent platform also controls the client platform display, so the user can be confident 
that what is seen on the display has not been subverted by an unauthorised process 
operating on the client platform. This aspect of the trusted component is also 
described below, but is more fully described in the applicant's copending International 

15 Patent Application No. PCT/GB 00/01996 entitled "System for Digitally Signing a 
Document" filed on 25 May 2000 and incorporated by reference herein. The system 
also employs in preferred embodiments a trusted token personal to a user - in the 
embodiment described in detail here, the trusted token is a user smart card. In 
addition, in the embodiment described, not only the client platform but also the server 

20 contains a trusted component (though this does need to have trusted display 
fimctionality). 

Certain elements of the system - the trusted component, including trusted display 
functionality, and the user smart card - will now be described in detail with reference 
25 to Figures 1 to 9. The skilled person will appreciate that in the context of the present 
invention, the specific form of trusted computing platform (and trusted component), 
trusted display and smart card are not critical, and may be modified without departing 
from the scope of the invention as claimed. 

30 To achieve a trusted computing platform, there is incorporated into the computing 
platform a physical trusted device whose function is to bind the identity of the 
platform to reliably measured data that provides an integrity metric of the platfonn. 
The trusted device may also (as is described below) act as a trusted display processor. 
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The trusted display processor (or a device with similar properties) is associated with 
video data at a stage in the video processing beyond the point where data can be 
manipulated by standard host computer software. This allows the trusted display 
processor to display data on a display surface without interference or subversion by 
5 the host computer software. Thus, the trusted display processor can be certain what 
image is currently being displayed to the user. The identity and the integrity metric 
are compared with expected values provided by a trusted party (TP) that is prepared to 
vouch for the trustworthiness of the platform. If there is a match, the imphcation is 
that at least part of the platform is operating correctly, depending on the scope of the 
10 integrity metric. 



A user verifies the correct operation of the platform before exchanging other data with 
the platform. A user does this by requesting the tmsted device to provide its identity 
and an integrity metric. (Optionally the trusted device will refiise to provide evidence 

15 of identity if it itself was unable to verify correct operation of the platform.) The user 
receives the proof of identity and the identity metric, and compares them against 
values which it believes to be tme. Those proper values are provided by the TP or 
another entity that is trusted by the user. If data reported by the trusted device is the 
same as that provided by the TP, the user trusts the platform. This is because the user 

20 trusts the entity. The entity tmsts the platfonn because it has previously validated the 
identity and determined the proper integrity metric of the platfonn. 

Once a user has established tmsted operation of the platform, he exchanges other data 
with the platform. For a local user, the exchange might be by interacting with some 
25 software application running on the platform. For a remote user, the exchange might 
involve a secure transaction. In either case, the data exchanged is 'signed' by the 
tmsted device. The user can then have greater confidence that data is being 
exchanged with a platform whose behaviour can be tmsted. 

30 The tmsted device uses cryptographic processes but does not necessarily provide an 
external interface to those cryptographic processes. Also, a most desirable 
implementation would be to make the trusted device tamperproof, to protect secrets 
by making them inaccessible to other platform fiinctions and provide an environment 
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that is substantially immune to unauthorised modification. Since tamper-proofing is 
impossible, the best approximation is a trusted device that is tamper-resistant, or 
tamper-detecting. The trusted device, therefore, preferably consists of one physical 
component that is tamper-resistant. 

5 

Techniques relevant to tamper-resistance are well known to those skilled in the art of 
security. These techniques include methods for resisting tampering (such as 
appropriate encapsulation of the tmsted device), methods for detecting tampering 
(such as detection of out of specification voltages. X-rays, or loss of physical integrity 

10 in the trusted device casing), and methods for eliminating data when tampering is 
detected. Further discussion of appropriate techniques can be found at 
http://www.cl.cam.ac.uk/-mgk25/tamper.html. It will be appreciated that, although 
tamper-proofing is a most desirable feature of the present invention, it does not enter 
into the normal operation of the invention and, as such, is beyond the scope of the 

15 present invention and will not be described in any detail herein. 

The tmsted device is preferably a physical one because it must be difficult to forge. It 
is most preferably tamper-resistant because it must be hard to counterfeit. It typically 
has an engine capable of using cryptographic processes because it is required to prove 
20 identity, both locally and at a distance, and it contains at least one method of 
measuring some integrity metric of the platform with which it is associated. 

Figure 1 illustrates a host computer system in which the host computer is (for 
example) a Personal Computer, or PC, which operates under the Windows NT^^ 

25 operating system. According to Figure 1, the host computer 100 is connected to a 
visual display unit (VDU) 105, a keyboard 110, a mouse 115 and a smartcard reader 
120, and a local area network (LAN) 125, which in turn is connected to the Intemet 
130. Herein, the smartcard reader is an independent unit, although it may be an 
integral part of the keyboard. The VDU, keyboard, mouse, and tmsted switch can be 

30 thought of as the human/computer interface (HCI) of the host computer. More 
specifically, the display, when operating under trusted control, as will be described, 
can be thought of as part of a *tmsted user interface'. Figure 1 also illustrates a 
smartcard 122 for use in the present embodiment as will be described. 
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Figure 2 shows a hardware architecture of the host computer of Figure 1. 

According to Figure 2, the host computer 100 comprises a central processing unit 
5 (CPU) 200, or main processor, connected to main memory, which comprises RAM 
205 and ROM 210, all of which are mounted on a motherboard 215 of the host 
computer 100. The CPU in this case is a Pentium™ processor. The CPU is connected 
via a PCI (Peripheral Component Interconnect) bridge 220 to a PCI bus 225, to which 
are attached the other main components of the host computer 100. The bus 225 
10 comprises appropriate control, address and data portions, which will not be described 
in detail herein. For a detailed description of Pentium processors and PCI 
architectures, which is beyond the scope of the present description, the reader is 
referred to the book, "The Indispensable PC Hardware Handbook", 3rd Edition, by 
Hans-Peter Messmer, published by Addison- Wesley, ISBN 0-201-40399-4. Of 
15 course, the present embodiment is in no way limited to implementation using Pentium 
processors, Windows™ operating systems or PCI buses. 

The other main components of the host computer 100 attached to the PCI bus 225 
include: a SCSI (small computer system interface) adaptor connected via a SCSI bus 

20 235 to a hard disk drive 2600 and a CD-ROM drive 2605; a LAN (local area network) 
adaptor 250 for connecting the host computer 100 to a LAN 125, via which the host 
computer 100 can communicate with other host computers (not shown), such as file 
servers, print servers or email servers, and the Internet 130; an lO (input/output) 
device 225, for attaching the keyboard 110, mouse 115 and smartcard reader 120; and 

25 a trusted device 260 (which incorporates the tmsted display processor function). The 
trusted display processor handles all standard display functions plus a number of 
further tasks, which will be described in detail below. 'Standard display functions' are 
those functions that one would normally expect to find in any standard host computer 
100, for example a PC operating under the Windows NT^^ operating system, for 

30 displaying an image associated with the operating system or application software. 
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All the main components, in particular the trusted device 260, are preferably also 
integrated onto the motherboard 215 of the host computer 100, although, sometimes, 
LAN adapters 250 and SCSI adapters 230 can be of the plugin type. 

5 Typically, in a personal computer the BIOS program is located in a special reserved 
memory area 215, the upper 64K of the first megabyte of the system memory 
(addresses F000h to FFFFh), and the main processor is arranged to look at this 
memory location first, in accordance with an industry wide standard. 

10 The significant difference between the platform and a conventional platform is that, 
after reset, the main processor is initially controlled by the trusted device, which then 
hands control over to the platform-specific BIOS program, which in turn initialises all 
input/output devices as normal. After the BIOS program has executed, control is 
handed over as normal by the BIOS program to an operating system program, such as 

15 Windows NT (TM), which is typically loaded into main memory fi-om a hard disk 
drive. 

Clearly, this change fi-om the nonnal procedure requires a modification to the 
implementation of the industry standard, whereby the main processor 200 is directed 
20 to address the trusted component (also described as trusted device) 260 to receive its 
first instructions. This change may be made simply by hard-coding a different address 
into the main processor 200. Alternatively, the trusted device 260 may be assigned 
the standard BIOS program address, in which case there is no need to modify the 
main processor configuration. 

25 

It is highly desirable for the BIOS boot block to be contained within the trusted device 
260. This prevents subversion of the obtaining of the integrity metric (which could 
otherwise occur if rogue software processes are present) and prevents rogue software 
processes creating a situation in which the BIOS (even if correct) fails to build the 
30 proper environment for the operating system. 

Although, in the preferred form to be described, the trusted device 260 is a single, 
discrete component, it is envisaged that the fiinctions of the trusted device 260 may 
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alternatively be split into multiple devices on the motherboard, or even integrated into 
one or more of the existing standard devices of the platform. For example, it is 
feasible to integrate one or more of the functions of the trusted device into the main 
processor itself, provided that the functions and their communications cannot be 

5 subverted. This, however, v^ould probably require separate leads on the processor for 
sole use by the trusted functions. Additionally or alternatively, although in the present 
embodiment the tmsted device is a hardv^^are device that is adapted for integration into 
the motherboard 215, it is anticipated that a trusted device may be implemented as a 
'removable' device, such as a dongle, which could be attached to a platform when 

10 required. Whether the trusted device is integrated or removable is a matter of design 
choice. However, where the trusted device is separable, a mechanism for providing a 
logical binding between the trusted device and the platform should be present. 

After system reset, the trusted device 260 performs a secure boot process to ensure 
15 that the operating system of the platform 100 (including the system clock and the 
display on the monitor) is running properly and m a secure manner. During the secure 
boot process, the trusted device 260 acquires an integrity metric of the computing 
platform 100. The trusted device 260 can also perform secure data transfer and, for 
example, authentication between it and a smart card via encryption/decryption and 
20 signature/verification. The trusted device 260 can also securely enforce various 
security control policies, such as locking of the user interface. Moreover, in this 
arrangement the trusted device 260 also acts as a trusted display processor, providing 
the standard display functions of a display processor and the extra, non-standard 
functions for providing a trusted user interface. 



According to Figure 3, the trusted device 260 comprises: 
a controller 300; 

non- volatile memory 305, for example flash memory, containing respective 
control program instmctions (i.e. firmware) for controlling the operation of the 
30 microcontroller 300 (alternatively, the trusted device 260 could be embodied in an 
ASIC, which would typically provide greater performance and cost efficiency in mass 
production, but would generally be more expensive to develop and less flexible) - the 
control program includes a measurement function 370 for acquiring the integrity 



25 
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metric from the computing platform and an authentication function 380 for 
authenticating a smart card (or other trusted component); 

an interface 310 for connecting the trusted device 260 to the PCI bus for 
receiving information including image data (i.e. graphics primitives) from the CPU 
5 200 and also trusted image data from the smartcard 122, as will be described; 

frame buffer memory 315, which comprises sufficient VRAM (video RAM) in 
which to store at least one fiill image frame (a typical frame buffer memory 315 is 1-2 
Mbytes in size, for screen resolutions of 1280x768 supporting up to 16.7 million 
colours); 

10 a video DAC (digital to analogue converter) 320 for converting pixmap data 

into analogue signals for driving the (analogue) VDU 105, which connects to the 
video DAC 320 via a video interface 325; 

volatile memory 335, for example DRAM (dynamic RAM) or more expensive 
SRAM (static RAM), for storing state information, particularly received 

15 cryptographic keys, and for providing a work area for the microcontroller 300; 

a cryptographic processor 340, comprising hardware cryptographic 
accelerators and/or software, arranged to provide the trusted device 260 with a 
cryptographic identity and to provide authenticity, integrity and confidentiality, guard 
against replay attacks, make digital signatures, and use digital certificates, as will be 

20 described in more detail below; and 

non- volatile memory 345, for example flash memory, for storing an identifier 
Idp of the trusted device 260 (for example a simple text string name - this can be used 
for indexing and labelling of data relevant to the tmsted device, but is in itself 
insufficient to prove the identity of the platform under tmsted conditions), a private 

25 key Sdp of the trusted device 260, a certificate Certop signed and provided by a trusted 
third party certification agency (TP), such as VeriSign Inc., which binds the tmsted 
device 260 with a signature public-private key pair and a confidentiality public- 
private key pair and includes the corresponding public keys of the trusted device 260. 

30 A certificate typically contains such information, but not the public key of the CA. 
That public key is typically made available using a 'Public Key Infi-astmcture' (PKI). 
Operation of a PKI is well known to those skilled in the art of security. 



wo 01/23980 © PCT/GBOO/03689 

16 

The certificate Certop is used to supply the public key of the trusted device 260 to 
third parties in such a way that third parties are confident of the source of the pubhc 
key and that the public key is a part of a valid public-private key pair. As such, it is 
unnecessary for a third party to have prior knowledge of, or to need to acquire, the 
public key of the trusted device 260. 

The certificate Tp (or, optionally, a further certificate) contains not only the public key 
of the trusted device 260 but also an authenticated value of the platform integrity 
metric measured by the trusted party (TP). In later conununications sessions, a user 
of the platform 100 can verify the integrity of the platform 100 by comparing the 
acquired integrity metric with the authentic integrity metric in the certificate. If there 
is a match, the user can be confident that the platform 10 has not been subverted. 
Knowledge of the TP's generally-available public key enables simple verification of 
the certificate. 

The trusted device 260 is equipped with at least one method of reliably measuring or 
acquiring the integrity metric of the computing platform 100 with which it is 
associated. In the present embodiment, the integrity metric is acquired by the 
measurement fimction 370 by generating a digest of the BIOS instructions in the 
BIOS memory. Such an acquired integrity metric, if verified as described above, 
gives a potential user of the platform 100 a high level of confidence that the platform 
100 has not been subverted at a hardware, or BIOS program, level. Other know 
processes, for example virus checkers, will typically be in place to check that the 
operating system and application program code has not been subverted. 

The measurement fimction 370 has access to: non-volatile memory 305,345 for 
storing a hash program 390 and a private key Sdp of the trusted device 260, and 
volatile memory 335 for storing acquired integrity metric in the form of a digest 361. 
In appropriate embodiments, the volatile memory 335 may also be used to store the 
) public keys and associated ID labels 360a-360n of one or more authentic smart cards 
122 that can be used to gain access to the platform 100. 
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In one preferred implementation, as well as the digest, the integrity metric includes a 
Boolean value, which is stored in volatile memory 335 by the measurement function 
370, for reasons that will become apparent. 

5 A preferred process for acquiring an integrity metric will now be described with 
reference to Figure 4. 

In step 500, at switch-on, the measurement function 370 monitors the activity of the 
main processor 200 on the PCI bus 225 to determine whether the trusted device 260 is 

10 the first memory accessed. Under conventional operation, a main processor would 
first be directed to the BIOS memory first in order to execute the BIOS program. 
However, in accordance with the arrangement shown, the main processor 200 is 
directed to the trusted device 260, which acts as a memory. In step 505, if the trusted 
device 260 is the first memory accessed, in step 510, the measurement function 370 

15 writes to volatile memory 335 a Boolean value which indicates that the trusted device 
260 was the first memory accessed. Otherwise, in step 515, the measurement function 
writes a Boolean value which indicates that the trusted device 260 was not the first 
memory accessed. 

20 In the event the trusted device 260 is not the first memory accessed, there is of course 
a chance that the tmsted device 260 will not be accessed at all. This would be the 
case, for example, if the main processor 200 were manipulated to run the BIOS 
program first. Under these circumstances, the platform would operate, but would be 
unable to verily its integrity on demand, since the integrity metric would not be 

25 available. Further, if the trusted device 260 were accessed after the BIOS program 
had been accessed, the Boolean value would clearly indicate lack of integrity of the 
platform. 

In step 520, when (or iO accessed as a memory by the main processor 200, the main 
30 processor 200 reads the stored native hash instructions 390 from the measurement 
function 370 in step 525. The hash instructions 390 are passed for processing by the 
main processor 200 over the data bus 225. In step 530, main processor 200 executes 
the hash instmctions 390 and uses them, in step 535, to compute a digest of the BIOS 
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memory 215, by reading the contents of the BIOS memory 215 and processing those 
contents according to the hash program. In step 540, the main processor 200 writes 
the computed digest 361 to the appropriate non- volatile memory location 335 in the 
trusted device 260. The measurement function 370, in step 545, then calls the BIOS 
5 program in the BIOS memory 215, and execution continues in a conventional manner. 

Clearly, there are a number of different ways in which the integrity metric may be 
calculated, depending upon the scope of the trust required. The measurement of the 
BIOS program's integrity provides a fundamental check on the integrity of a 

10 platform's underlying processing environment. The integrity metric should be of such 
a form that it will enable reasoning about the validity of the boot process - the value of 
the integrity metric can be used to verify whether the platform booted using the 
correct BIOS. Optionally, individual functional blocks within the BIOS could have 
their own digest values, with an ensemble BIOS digest being a digest of these 

15 individual digests. This enables a policy to state which parts of BIOS operation are 
critical for an intended purpose, and which are irrelevant (in which case the individual 
digests must be stored in such a manner that validity of operation under the policy can 
be established). 

20 Other integrity checks could involve establishing that various other devices, 
components or apparatus attached to the platform are present and in correct working 
order. In one example, the BIOS programs associated with a SCSI controller could be 
verified to ensure communications with peripheral equipment could be trusted. In 
another example, the integrity of other devices, for example memory devices or co- 

25 processors, on the platform could be verified by enacting fixed challenge/response 
interactions to ensure consistent results. Where the trusted device 260 is a separable 
component, some such form of interaction is desirable to provide an appropriate 
logical binding between the trusted device 260 and the platform. Also, although in the 
present embodiment the trusted device 260 utilises the data bus as its main means of 

30 communication with other parts of the platform, it is feasible to provide alternative 
communications paths, such as hard-wired paths or optical paths - such an 
arrangement is described in greater detail below with reference to Figures 8 and 9. 
Fiuther, although in the present embodiment the trusted device 260 instructs the main 
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processor 200 to calculate the integrity metric in other embodiments, the trusted 
device itself is arranged to measure one or more integrity metrics. 



Preferably, the BIOS boot process includes mechanisms to verify the integrity of the 
5 boot process itself. Such mechanisms are already known from, for example, Intel's 
draft "Wired for Management baseline specification v 2,0 - BOOT Integrity Service'', 
and involve calculating digests of software or firmware before loading that software 
or firmware. Such a computed digest is compared with a value stored in a certificate 
provided by a trusted entity, whose public key is known to the BIOS. The 
10 software/firmware is then loaded only if the computed value matches the expected 
value from the certificate, and the certificate has been proven valid by use of the 
tmsted entity's public key. Otherwise, an appropriate exception handling routine is 
invoked. 



15 Optionally, after receiving the computed BIOS digest, the trusted device 260 may 
inspect the proper value of the BIOS digest in the certificate and not pass control to 
the BIOS if the computed digest does not match the proper value. Additionally, or 
alternatively, the trusted device 260 may inspect the Boolean value and not pass 
control back to the BIOS if the tmsted device 260 was not the first memory accessed. 

20 In either of these cases, an appropriate exception handling routine may be invoked. 



Figure 5 illustrates the flow of actions by a TP, the trusted device 260 incorporated 
into a platform, and a user (of a remote platform) who wants to verify the integrity of 
the tmsted platform. It will be appreciated that substantially the same steps as are 

25 depicted in Figure 5 are involved when the user is a local user In either case, the user 
would typically rely on some form of software application to enact the verification. It 
would be possible to run the software application on the remote platform or the 
trusted platfomi. However, there is a chance that, even on the remote platform, the 
software application could be subverted in some way. Therefore, it is anticipated that, 

30 for a high level of integrity, the software application would reside on a smart card of 
the user, who would insert the smart card into an appropriate reader for the purposes 
of verification. Figure 5 illustrates the flow of actions for the general case - a more 
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specific flow of actions for verification by a user smart card will be described with 
reference to Figure 6 fiulher below. 



At the first instance, a TP, which vouches for trusted platforms, will inspect the type 
5 of the platform to decide whether to vouch for it or not. This will be a matter of 
policy. If all is well, in step 600, the TP measures the value of integrity metric of the 
platform. Then, the TP generates a certificate, in step 605, for the platform. The 
certificate is generated by the TP by appending the trusted device's public key, and 
optionally its ID label, to the measured integrity metric, and signing the string with 
1 0 the TP's private key. 

The trusted device 260 can subsequently prove its identity by using its private key to 
process some input data received from the user and produce output data, such that the 
input/output pair is statistically impossible to produce without knowledge of the 

15 private key. Hence, knowledge of the private key forms the basis of identity in this 
case. Clearly, it would be feasible to use symmetric encryption to form the basis of 
identity. However, the disadvantage of using symmetric encryption is that the user 
would need to share his secret with the tmsted device. Further, as a result of the need 
to share the secret with the user, while symmetric encryption would in principle be 

20 sufficient to prove identity to the user, it would insufficient to prove identity to a third 
party, who could not be entirely sure the verification originated fi-om the trusted 
device or the user. 



In step 610, the trusted device 260 is initialised by writing the certificate into the 
25 appropriate non-volatile memory locations of the tmsted device 260. This is done, 
preferably, by secure communication with the trusted device 260 after it is installed in 
the motherboard 215. The method of writing the certificate to the trusted device 260 
is analogous to the method used to initialise smart cards by writing private keys 
thereto. The secure communications is supported by a 'master key', known only to 
30 the TP, that is written to the tmsted device (or smart card) during manufacture, and 
used to enable the writing of data to the tmsted device 260; writing of data to the 
trusted device 260 without knowledge of the master key is not possible. 
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At some later point during operation of the platform, for example when it is switched 
on or reset, in step 615, the trusted device 260 acquires and stores the integrity metric 
of the platform. 

5 When a user wishes to communicate with the platform, in step 620, he creates a 
nonce, such as a random number, and, in step 625, challenges the trusted device 260 
(the operating system of the platform, or an appropriate software application, is 
arranged to recognise the challenge and pass it to the trusted device 260, typically via 
a BIOS-type call, in an appropriate fashion). The nonce is used to protect the user 

10 from deception caused by replay of old but genuine signatures (called a 'replay 
attack') by untrustworthy platforms. The process of providing a nonce and verifying 
the response is an example of the well-known 'challenge/response' process. 

In step 630, the trusted device 260 receives the challenge and creates an appropriate 
15 response. This may be a digest of the measured integrity metric and the nonce, and 
optionally its ID label. Then, in step 635, the trusted device 260 signs the digest, 
using its private key, and returns the signed digest, accompanied by the certificate 
Certop, to the user. 

20 In step 640, the user receives the challenge response and verifies the certificate using 
the well known public key of the TP. The user then, in step 650, extracts the trusted 
device's 260 public key from the certificate and uses it to decrypt the signed digest 
from the challenge response. Then, in step 660, the user verifies the nonce inside the 
challenge response. Next, in step 670, the user compares the computed integrity 

25 metric, which it extracts from the challenge response, with the proper platform 
integrity metric, which it extracts from the certificate. If any of the foregoing 
verification steps fails, in steps 645, 655, 665 or 675, the whole process ends in step 
680 with no fiirther communications taking place. 

30 Assuming all is well, in steps 685 and 690, the user and the tmsted platform use other 
protocols to set up secure communications for other data, where the data from the 
platform is preferably signed by the trusted device 260. 
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Further refinements of this verification process are possible. It is desirable that the 
challenger becomes aware, through the challenge, both of the value of the platform 
integrity metric and also of the method by which it was obtained. Both these pieces of 
infomiation are desirable to allow the challenger to make a proper decision about the 
5 integrity of the platform. The challenger also has many different options available - it 
may accept that the integrity metric is recognised as valid in the trusted device 260, or 
may alternatively only accept that the platform has the relevant level of integrity if the 
value of the integrity metric is equal to a value held by the challenger (or may hold 
there to be different levels of trast in these two cases). 

10 

The techniques of signing, using certificates, and challenge/response, and using them 
to prove identity, are well known to those skilled in the art of security and therefore 
need not be described in any more detail herein. 

15 In preferred arrangements of the system, a user employs a smart card 122 to verify a 
trasted platfoim. The processing engine of a smartcard suitable for use in accordance 
with the preferred embodiment is illustrated in Figure 7. The processing engine 
comprises a processor 400 for enacting standard encryption and decryption functions, 
to support verification of information received firom elsewhere. In the present 

20 embodiment, the processor 400 is an 8-bit microcontroller, which has a buiU-in 
operating system and is arranged to communicate with the outside world via 
asynchronous protocols specified through ISO 7816-3, 4, T=0, T=l and T=14 
standards. The smartcard also comprises non-volatile memory 420, for example flash 
memory, containing an identifier Isc of the smartcard 122, a private key Ssc, used for 

25 digitally signing data, and a certificate Certsc, provided by a trusted third party 
certification agency, which binds the smartcard with public-private key pairs and 
includes the corresponding public keys of the smartcard 122 (the same in nature to the 
certificate Certop of the trusted device 260). Further, the smartcard contains 'seal' 
data SEAL in the non-volatile memory 420, which can be represented graphically by 

30 the tmsted display processor 260 to indicate to the user that a process is operating 
securely with the user's smartcard, as will be described in detail below. In the present 
embodiment, the seal data SEAL is in the form of an image pixmap, which was 
originally selected by the user as a unique identifier, for example an image of the user 
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himself, and loaded into the smartcard 122 using well-known techniques. The 
processor 400 also has access to volatile memory 430, for example RAM, for storing 
state information (such as received keys) and providing a working area for the 
processor 400, and an interface 440, for example electrical contacts, for 
5 communicating with a smart card reader. 

Seal images can consume relatively large amounts of memory if stored as pixmaps. 
This may be a distinct disadvantage in circumstances where the image needs to be 
stored on a smartcard 122, where memory capacity is relatively Umited. The memory 

10 requirement may be reduced by a number of different techniques. For example, the 
seal image could comprise: a compressed image, which can be decompressed by the 
trusted device 260; a thumb-nail image that forms the primitive element of a repeating 
mosaic generated by the trusted device 260; a naturally compressed image, such as a 
set of alphanumeric characters, which can be displayed by the trusted device 260 as a 

15 single large image, or used as a thumb-nail image as above. In any of these 
alternatives, the seal data itself may be in encrypted form and require the trusted 
device 260 to decrypt the data before it can be displayed. Altematively, the seal data 
may be an encrypted index, which identifies one of a number of possible images 
stored by the host computer 100 or a network server. In this case, the index would be 

20 fetched by the trusted device 260 across a secure channel and decrypted in order to 
retrieve and display the correct image. Further, the seal data could comprise 
instructions (for example PostScript™ instructions) that could be interpreted by an 
appropriately programmed trusted device 260 to generate an image. 

25 As indicated above. Figure 6 shows the flow of actions in an example of verification 
of platform integrity by a user interacting with the trusted platform with a smart card 
122. As will be described, the process conveniently implements a challenge/response 
routine. There exist many available challenge/response mechanisms. The 
implementation of an authentication protocol used in the present embodiment is 

30 mutual (or 3-step) authentication, as described in ISO/IEC 9798-3, "Information 
technology - Security techniques - Entity authentication mechanisms; Part 3; Entity 
authentication using a public key algorithm'*. International Organization for 
Standardization, November 12293. Of course, there is no reason why other 
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authentication procedures cannot be used, for example 2-step or 4-step, as also 
described in this reference. 

Initially, the user inserts their smart card 122 into the smart card reader 120 of the 
5 platform in step 700. 

Beforehand, a platform configured for use by users of in this way will typically be 
operating under the control of its standard operating system and executing the 
authentication process, which waits for a user to insert their smart card 122. Apart 
10 from the smart card reader 120 being active in this way, such a platform is typically 
rendered inaccessible to users by Mocking' the user interface (i.e. the screen, keyboard 
and mouse). 

When the smart card 122 is inserted into the smart card reader 120, the trusted device 
15 260 is triggered to attempt mutual authentication in step by generating and 
transmitting a nonce A to the smart card 122 in step 705. A nonce, such as a random 
number, is used to protect the originator from deception caused by replay of old but 
genuine responses (called a 'replay attack') by untrustworthy third parties. 

20 In response, in step 710, the smart card 122 generates and returns a response 
comprising the concatenation of: the plain text of the nonce A, a new nonce B 
generated by the smart card 122, an ID of the trusted device 260 and some 
redundancy; the signature of the plain text, generated by signing the plain text with 
the private key of the smart card 122; and a certificate containing the ID and the 

25 pubhc key of the smart card 122. 

The trusted device 260 authenticates the response by using the public key in the 
certificate to verify the signature of the plain text in step 715. If the response is not 
authentic, the process ends in step 720. If the response is authentic, in step 725 the 
30 trasted device 260 generates and sends a ftirther response including the concatenation 
of: the plain text of the nonce A, the nonce B, an ID of the smart card 122 and the 
acquired integrity metric; the signature of the plain text, generated by signing the 
plain text using the private key of the trusted device 260; and the certificate 
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comprising the public key of the trusted device 260 and the authentic integrity metric, 
both signed by the private key of the TP. 

The smart card 122 authenticates this response by using the pubHc key of the TP and 
5 comparing the acquired integrity metric with the authentic integrity metric, where a 
match indicates successful verification, in step 730. If the further response is not 
authentic, the process ends in step 735. 

If the procedure is successful, both the trusted device 260 has authenticated the smart 
10 card 122 and the smart card 122 has verified the integrity of the trusted platform and, 
in step 740, the authentication process executes the secure process for the user. 

In certain types of interaction, the authentication process can end at this point. 
However, if a session is to be continued between the user and the trusted platform, it 
15 is desirable to ensure that the user remains authenticated to the platform. 

Where continued authentication is required, the authentication process sets an interval 
timer in step 745. Thereafter, using appropriate operating system interrupt routines, 
the authentication process services the interval timer periodically to detect when the 
20 timer meets or exceeds a pre-determined timeout period in step 750. 

Clearly, the authentication process and the interval timer run in parallel with the 
secure process. When the timeout period is met or exceeded, the authentication 
process triggers the trusted device 260 to re- authenticate the smart card 122, by 

25 transmitting a challenge for the smart card 122 to identify itself in step 760. The 
smart card 122 returns a certificate including its ID and its public key in step 765. In 
step 770, if there is no response (for example, as a result of the smart card 122 having 
been removed) or the certificate is no longer valid for some reason (for example, the 
smart card has been replaced with a diflferent smart card), the session is terminated by 

30 the trusted device 260 in step 775. Otherwise, in step 770, the process firom step 745 
repeats by resetting the interval timer. 
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Additionally, or alternatively, in some embodiments it may be required that the user 
profile is encrypted and signed to protect privacy and integrity. If so, a secure data 
transfer protocol may be needed between the trusted device 260 and the smart card 
122. There exist many available mechanisms for transferring secure credentials 
5 between two entities. A possible implementation, which may be used in the present 
embodiment, is secure key transport mechanisms from ISO/EEC DIS 11770-3, 
"Information technology - Security techniques - Key management - Part 3: 
Mechanisms using asymmetric techniques", Intemational Organization for 
Standardization, March 1997. 

10 

Modifications of this verification process using other well-known challenge and 
response techniques can easily be achieved by the skilled person. Similarly, 
alternative verification processes can be used by parties interacting with the platform 
in a different manner (that is, other than as a user equipped with a smart card). 

15 

As described above, the trusted device 260 lends its identity and tmsted processes to 
the host computer and the tmsted display processor has those properties by virtue of 
its tamper-resistance, resistance to forgery, and resistance to counterfeiting. Only 
selected entities with appropriate authentication mechanisms are able to influence the 
20 processes running inside the tmsted device 260. Neither an ordinary user of the host 
computer, nor any ordinary user or any ordinary entity connected via a network to the 
host computer may access or interfere with the processes mnning inside the trusted 
device 260. The tmsted device 260 has the property of being "inviolate". 

25 It will be apparent from Figure 3 that the frame buffer memory 315 is only accessible 
by the tmsted display processor 260 itself, and not by the CPU 200. This is an 
important feature of the preferred embodiment, since it is imperative that the CPU 
200, or, more importantly, subversive apphcation programs or vimses, carmot modify 
the pixmap during a tmsted operation. Of course, it would be feasible to provide the 

30 same level of security even if the CPU 200 could directly access the frame buffer 
memory 315, as long as the tmsted display processor 260 were arranged to have 
ultimate control over when the CPU 200 could access the frame buffer memory 315. 
Obviously, this latter scheme would be more difficult to implement. 



wo 01/23980 




PCT/GBOO/03689 



A typical process by which graphics primitives are generated by a host computer 100 
will now be described by way of background. Initially, an application program, which 
wishes to display a particular image, makes an appropriate call, via a graphical API 

5 (application programming interface), to the operating system. An API typically 
provides a standard interface for an application program to access specific underlying 
display functions, such as provided by Windows NT™, for the purposes of displaying 
an image. The API call causes the operating system to make respective graphics 
driver library routine calls, which result in the generation of graphics primitives 

10 specific to a display processor, which in this case is the trusted display processor 260. 
These graphics primitives are finally passed by the CPU 200 to the trasted display 
processor 260. Example graphics primitives might be 'draw a line fi-om point x to 
point y with thickness z' or 'fill an area bounded by points w, x, y and z with a colour 
a'. 

15 

The control program of the microcontroller 300 controls the microcontroller to 
provide the standard display fimctions to process the received graphics primitives, 
specifically: 

receiving fi-om the CPU 200 and processing graphics primitives to form 
20 pixmap data which is directly representative of an image to be displayed on the VDU 
105 screen, where the pixmap data generally includes intensity values for each of the 
red, green and blue dots of each addressable pixel on the VDU 105 screen; 

storing the pixmap data into the firame buffer memory 315; and 
periodically, for example sixty times a second, reading the pixmap data fi*om the 
25 fi-ame buffer memory 315, converting the data into analogue signals using the video 
DAC and transmitting the analogue signals to the VDU 105 to display the required 
image on the screen. 

Apart from the standard display functions, the control program includes a function to 
30 mix display image data deceived from the CPU 200 with trusted image data to form a 
single pixmap. The control program also manages interaction with the cryptographic 
processor. 
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The trasted display processor 260 forms a part of the overall 'display system' of the 
host computer 100; the other parts typically being display functions of the operating 
system, which can be 'called' by application programs and which access the standard 
display functions of the graphics processor, and the VDU 105. In other words, the 
5 'display system' of a host computer 100 comprises every piece of hardware or 
functionahty which is concerned with displaying an image. 

Referring now to Figure 8, a preferred arrangement is shown in which trusted 
communication paths are provided for use by the tmsted component 260. Such an 

10 arrangement is described more fully in the applicant's copending International Patent 
Application No. PCT/GB 00/00504 entitled "Communication between Modules of a 
Computing Apparatus" filed on 15 Febmary 2000 and incorporated by reference 
herein. In Figure 8 (in which only some of the elements of Figure 2 are shown), a 
host computer 100 has a main CPU 200, a SCSI interface 230, a PCI network 

15 interface card 106 and DRAM memory 205 with conventional ("normal") 
communications paths 110 (such as ISA, EISA, PCI, USB) therebetween. The 
network interface card 106 also has an external commvmication path 112 with the 
world outside the host computer 100. 

20 The network interface card 106 is logically divided into "red" and "black" data zones 
1 14,1 16 with an interface 1 1 8 therebetween. In the red zone 1 14, data is usually plain 
text and is sensitive and vulnerable to undetectable alteration and undesired 
eavesdropping. In the black data zone 116, data is protected from undetected 
alteration and undesired eavesdropping (preferably encrypted by standard crypto 

25 mechanisms). The interface 118 ensures that red information does not leak into the 
black zone 116. The interface 118 preferably uses standard crypto methods and 
electronic isolation techniques to separate the red and black zones 114,116. The 
design and constmction of such red and black zones 1 14,1 16 and the interface 1 18 is 
well known to those skilled in the art of security and electronics, particularly in the 

30 mihtary field. The normal communication path 110 and external communication path 
112 connect with the black zone 1 1 6 of the network interface card 106. 
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The host computer 100 also includes a trusted module 260 which is coraiected, not 
only to the normal communication paths 110, but also by mutually separate additional 
communication paths 122 (sub-referenced 122a, 122b, 122c) to the CPU 220, SCSI 
interface 230 and the red zone 114 of the network interface card 106. Other 
5 arrangements are possible, and not all components are provided with such dedicated 
communications paths - by way of example, the trusted module 260 does not have 
such a separate additional communication path 122 with the memory 205. 

The trusted module 260 can communicate with the CPU 102, SCSI interface 230 and 
10 red zone 114 of the network interface card 106 via the additional communication 
paths 122a,b,c, respectively. It can also communicate with the CPU 260, SCSI 
interface 230, black zone 116 of the network interface card 106 and the memory 205 
via the normal communication paths 110. The trasted module 260 can also act as a 
lOOVG switching centre to route certain information between the CPU 200, SCSI 
15 interface 230 and the red zone 1 14 of the network interface card 106, via the trusted 
module 260 and the additional communication paths 122, under control of a policy 
stored in the trusted module. The tmsted module 260 can also generate cryptographic 
keys and distribute those keys to the CPU 200, the SCSI interface 230, and the red 
zone 114 of the network interface card 106 via the additional communication paths 
20 122a,b,c, respectively. 

Figure 9 illustrates the process by which incoming external secure messages are 
processed when the tmsted module 260 is the only module in the platform with 
cryptographic capabilities. An external message 146 is received by the black zone 116 

25 of the network interface card 106 using the external communication path 112. The 
network interface card 106 sends a protocol data unit 148 containing some data and a 
request for an authentication and integrity check to the tmsted module 260 using the 
normal communication paths 110. The tmsted module 260 performs the 
authentication and integrity checks using the long term keys inside the trusted module 

30 260 that must not revealed outside the trusted module 260, and sends a protocol data 
unit 150 containing an 'OK' indication to the red zone 114 of the network interface 
card 106 using the additional communication path 122c. The network interface card 
106 then sends a protocol data unit 152 containing some data and a request for 
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decryption to the trusted module 260 using the normal communication paths 1 1 0. The 
trusted module 260 decrypts the data using either temporary or long term keys inside 
the trusted module 260, and sends a protocol data unit 154 containing the decrypted 
data to the CPU 200 using the additional communication path 122a. The CPU then 
5 takes appropriate action. 

A system for implementing a specific embodiment of the invention will now be 
described with reference to Figure 10. 

10 The user logs into a client trusted platform 1001, in preferred arrangement with the 
assistance of a user smart card 1008 connecting to the client tmsted platform 1001 
through a smart card reader 1007. The chent trusted platform, smart card and 
interaction therebetween may be essentially as described in Figures 1 to 9 above 
(although this is not essential for implementation of all embodiments of the 
15 invention). Within the cHent trusted platform there is therefore a client trusted 
component 1003 which contains a display processor such that the output on the 
display 1005 is controlled by the client trusted component, and is therefore reliable. 
Also contained within the client trusted platfonn 1001 are an area of memory 
containing remote imaging code 1004 and an area of protected memory 1009. These 
20 need to be available for reliable use. Ideally, these might be sited within the trusted 
component 1003 itself - this however may result in the trusted component being 
expensive to produce (provision of some or all of the protected memory 1009 within a 
trusted component is a balance between security and cost). A potentially cheaper 
altemative, shown in Figure 10, is for the protected memory 1009 and the remote 
25 imaging code 1004 to be located outside the trusted component 1003 but connected to 
it by secure communication paths 1 102 (preferably a dedicated communications link, 
ideally hardwired and isolated from any other components of the client trusted 
platform 1001, essentially as described in Figures 8 and 9). If the protected memory 
1009 and the remote imaging code 1004 are located on the client tmsted platform in 
30 such a way that they are accessible to any component of the client trusted platform 
other than the client tmsted component 1003, it is desirable at least that their integrity 
is monitored by the client trusted component, for example as described in the 
s^plicant's copending International Patent Application No. PCT/GB 00/02003 entitled 
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"Data Integrity Monitoring in Trusted Computing Entity" filed on 25 May 2000, 
which is incorporated by reference herein. The cHent trusted platform 1001 will 
contain components as shown in Figure 1 (including a keyboard or other such devices 
for user input) which need not be described further here. 

5 

The display 1005 operates under the control of the chent trusted component 1003. In 
a preferred arrangement (as will be described further below), a selected area of pixels 
1006 in the display are arranged to operate under direct control of a remote server 
when the system is operating in client/server mode. It will be appreciated that a 

10 display 1005 is not the only possible way of providing data to a user - rather than 
image data, the server may provide audio data or video data to be played in part by an 
audio player (preferably a secure audio player protected from subversion in the same 
manner as display 1005 - less effective in the case of an audio player, because of the 
greater ease of re-recording the content from the playback in the case of audio) or may 

15 provide other forms of output to the user altogether. In implementation of the present 
invention, the functional purpose of the data is not critical - it is the protection of the 
data from unauthorised use that is significant. 

The client trusted component 1003 ensures that the image output on the display 1005 
20 corresponds to the execution of the data. The chent trusted component is also 
required for authentication of the server tmsted component 1106 (see below). 
Advantageously, the client trusted component is also adapted to verify the data 
protection capabilities of the server trusted component 1 106. Other roles which may 
be required of the client trasted component 1003 are verification of a user smart card 
25 1008 where employed and also to provide trustworthy performance-related 
information - whether indication of trustworthiness of the platform in executing code, 
or reliable metering of code or data execution, provision of reports or of billing 
information. 

30 The server 1109 is in this arrangement also a trusted platform of the kind described 
with reference to Figures 1 to 9 (though trasted display functionality is probably not 
required, and other arrangements are clearly possible). The server 1109 contains a 
server trasted component 1106 and an area of memory containing remote image 
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sending code 1 103, together with a memory to store application data 1 107. Again, the 
remote image sending code 1103 in particular may reside within the server trusted 
component 1106, or one of the alternative arrangements described with reference to 
the client tmsted component 1003 employed. 

5 

The server trusted component 1106 needs to be able to authenticate the client trusted 
component 1003, the user smart card 1008, or both, depending on the usage model. It 
may also need to be adapted to hold information relating to the client (registration 
information, client data, or chent billing data) securely - either in the server trusted 
10 component 1 106 itself, or in associated memory which is monitored by the server 
trusted component 1106. Again, it may be desirable for billing, reporting and 
metering capabihties to be included within the server trusted component 1 106. 

The user smart card 1008, where used, will generally need to be able to authenticate 
15 either the client trusted component 1003, the server tmsted component 1 106, or both. 
It may also be desirable for the user smart card 1008 to be able to verify the data 
protection capabilities of the server tmsted component 1 106. 

The image sending code 1103 must be adapted to determine whether the client 
20 platform is adapted to handle the image code securely (preferably this will involve 
authentication of the client trusted component and will be best handled within the 
server tmsted component) and whether the client platfomi (or a smart card in session 
with it) is licensed or otherwise permitted to receive image data. The image sending 
code must also be adapted to receive and interpret requests for image data (or for data 
25 execution) received from the client platform. The image sending code may also be 
required to obtain user account information from the client platform or a user smart 
card. The image sending code 1103 also needs to be able to engage in secure 
communication with the client platform (perhaps with the assistance of a 
cryptographic processor within the server tmsted component. 

30 

The image receiving code 1004 must be adapted to communicate with the server - 
both to make requests for image data directly, or for code to execute on the server, 
and to receive image data from the server. It is desirable for the image receiving code 
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to be trusted by the server, the user, or any other party interacting with the chent 
platform. It is therefore preferred that on booting up of the chent platform, the client 
trusted component measures an integrity metric of the image receiving code 1004 
(and alerts the user, or even fails to boot, if the integrity metric does not match with 
5 the stored metric). Again, the image receiving code 1004 will need to interact with a 
cryptographic processor (perhaps within the client trusted component), perhaps along 
a secure conununication path of the type shown in Figure 8, in order to communicate 
securely with the server. 

10 The basic principle of operation is that applications are (in whole or in part) run on the 
server 1109. Mutual authentication of the server trusted component 1106 and the 
client trusted component 1003 (or perhaps of the user tmsted component on smartcard 
1008) is first achieved (essentially as described in Figure 5) to allow the application to 
be run. When the application is run, the server 1109 provides securely image data 

15 1108 to the client trusted component 1003 which is then used to drive the display 
1005. User data will be required for useful operation. This is provided by user input 
at the client platform (or in some cases from data stored in the client platform) and 
sent back (user data message 1010), again securely, to the server 1109 for use by the 
application. Such communication is repeated whenever updates are required to the 

20 display 1005 or when user input is required. 

This process may operate according to any of a number of different operational 
models. The trusted server 1109 may be controlled by a software developer, and be 
used as a way of offering trial software to a user, or to enable a user to use software 

25 on a metered basis. The tmsted server operator need not be a software developer, 
even for this purpose, but may instead be another party trusted by the software 
developer to execute the data on their platform (or alternatively to relay an image 
obtained from a developer). A ftirther possibility is for the tmsted server to be 
controlled by an internet service provider offering acting as an intermediary between 

30 users and software developers. 

In essence, the arrangement allows for a "service provider" (in the most general sense) 
to provide information to (effectively, to control) some or all of a user's screen with a 
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degree of security, that the information provided by the service provider will not be 
put to an unintended use. This may therefore be an effective way to provide content 
(perhaps particularly effective for interactive content) on a metered basis. As the 
service provider has effective control of the display 1005, a reserved zone 1006 may 

5 be used for purposes selected by the service provider rather than the user - such as for 
display of advertising, proprietary information, or other information not directly 
associated with the user-requested service (trial software, content provision, etc.). 
This server-determined information could be provided within a defined area (as 
shown in Figure 10) or over different areas (for example, the whole screen at a 

10 predetermined time interval or during pauses in code operation or the user-requested 
information), and may be static or change with time (e.g. streaming video) and could 
be supplemented with audio information. 

A number of different models for running services over such an arrangement can be 
15 employed. In the simplest form, "licensed" data is executed on the server, and not on 
the client. In return for payment, the client receives imaging information 
corresponding to the execution of the data on the tmsted server. This is sent via the 
remote image sending code on the server. Thereafter, the remote image receiving code 
on the client machine sends to the server keyboard strokes, corresponding to the 
20 selections of the user, and receives in return imaging information, corresponding to 
the changing execution of the application. The imaging information is sent directly 
from the trusted server via a secure channel such as PPTP to the trusted component 
within the client, which is adapted to display the imaging information directly without 
having to involve any untmsted parts of the computing apparatus. 

25 

It is not efficient in all cases to run all software on the server rather than the client. For 
relatively sensitive information (this might apply for data access, or where there may 
be substantial overlap each time the software mns) it might be applicable to store 
temporarily all of the image in client protected memory, and have the software 
30 displayed on the client, but actually running on the server. The client at no stage stores 
the software apart from the image stored in the protected memory, and therefore is not 
liable to licence infiingement attacks on the data via the hard disk or other storage 
media. For less sensitive information, and especially where an application may 
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produce differing images each time it is run, as is usually the case with game 
software, it would probably be more appropriate to run the software only partly from 
the server; for example, essentially mnning locally, but needing certain critical input 
from the server (such as an on-line service) in order to run the software. The server 

5 must still have overall control, so that although the client machine may be able to run 
the program, the run cannot succeed without the server being involved. There are 
different ways of carrying this out: for example, the server could supply key bits of 
the information, and transmit the image in communal blocks which would be the same 
for all clients, with the client tmsted component repeatedly authenticating to the 

10 server tmsted component for personalised information or key bits; or some of the data 
could be stored locally, with the server transmitting additional data to the protected 
memory. For the sake of efficiency, during and after execution, only part of the 
information (such as the key bits) is stored in the protected memory, and the rest can 
be stored on the hard disk or other storage media. This partial model of image transfer 

15 can be used concurrently with total models for different data on the same server. 

A procedure by which the arrangement of Figure 10 is operated such that client 
tmsted platform 1001 acts as a "trusted terminal" for display of image data from 
tmsted server 1109 will now be described with reference to Figure 11. This 
20 arrangement may be useftil for any of the "services" indicated above: for example, 
when the user of the cUent tmsted platform 1001 wishes to view (but not acquire) a 
document or wishes to use software on a pay-per-use basis. 

In the arrangement shown in Figure 1 1, a user smart card 1008 is used to provide the 
25 user interaction with the server 1109, with the client trusted component 1003 serving 

to confirm that the client 1001 can provide a tmsted display and acting as an 

intermediary between the user smart card 1008 and the client tmsted component 1003. 

In alternative arrangements, the client tmsted component 1003 may act for the user, 

rather than the user smart card 1008, in which case interactions between the user 
30 smart card 1008 and the server 1109 (generally the server tmsted component 1106) 

may be replaced by interactions between the client trasted component 1003 and the 

server 1 109. 
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The first phase, consisting of initial set-up to allow the "trusted terminal" operation of 
the client trusted platform 1001 to function, may take place either when trusted 
terminal functionality is required or at any earlier time. If interaction is to be between 
the trusted server 1 109 and the user smart card 1008, the initial set-up phase need not 

5 employ the client trusted platform 1001 at all - another client trusted platform could 
be used (an advantage of registering with a smart card may be the ability then to use 
essentially any client trusted platform with trusted display functionality to access the 
data or operations for which the smart card is registered. Alternatively, all the set-up 
steps could be replaced by the issuance of a specific smart card 1008 adapted to allow 

10 trusted terminal execution for specific data or operations on the trusted server 1109 
(this could be a smart card used as an auxiliary to a user's main smart card - an 
arrangement for carrying this out is described in the applicant's copending 
International Patent Application No. PCT/GB 00/00751 entitled "Computing 
Apparatus and Methods of Operating Computing Apparatus" filed on 3 March 2000, 

15 the contents of which are incorporated by reference herein). 



At the start of the first phase the user registers (step 1100) his smart card 1008 (or 
client platform 1001, as indicated above - registration of a client platform rather than a 
smart card is not explicitly described hereafter) with the tmsted server 1109. At this 

20 stage, a payment mechanism may be arranged. A simple approach (step 1 105) is for 
the smart card 1 008 to be charged up with credit to cover a certain quantity of data 
purchase or code usage, but other models (such as provision of billing details plus 
establishment of a mechanism for secure logging and reporting of usage data, by or to 
the smart card, a client platform, the trusted server or elsewhere) are possible. If it has 

25 not already been received in the registration step 1100, the smart card 1008 now 
provides its pubHc key to the trusted server 1109 (step 1110). In return, the trasted 
server 1109 installs the public key certificate of the server trusted component 1106 
into the user smart card 1008 (step 1115). This allows authentication of the trusted 
server 1 109 by the smart card 1008: in response to an authorisation request by the user 

30 smart card 1008 incorporating a nonce, the trusted server 1109 returns a message 
including its public key certificate and the nonce, signed with its private key; the user 
smart card can thus check that the message truly originated fi-om the trusted server 
1109. Preferably (step 1120) the user checks that the trusted server can indeed be 



wo 01/23980 ^ PCT/GBOO/03689 

37 

trasted, using the user smart card 1008 to verify the protection capabilities of server 
trusted component 1106 (from integrity metrics or other trasted data held or 
obtainable by or with reference to the server trasted component 1 106). 

5 The second phase is data execution, and requires use of a client platform with a 
tmsted display. The first step is the request (generally via the operating system on the 
client trasted platform 1001) for data to be displayed which is only obtainable from 
trasted server 1109 (step 1 125). For the smart card model, the user smart card 1008 
now needs to be in session with a client trasted platform 1001. The next step (step 
10 1130) is one of mutual authentication between the different trasted components 
present: user smart card 1008, client trasted component 1003 and server trasted 
component 1 106, for the arrangement described in Figure 11. Optionally, in the case 
of authentication between the user smart card 1008 and the client trasted component 
1003, a special displayed message personal to the user smart card 1008 (a seal image) 
15 may be displayed on the display 1005 at this point (this process is described in more 
detail in the applicant's copending International Patent Application No. PCT/GB 
00/012296, entitled "System for Digitally Signing a Document", filed on 25 May 
2000 and incorporated herein by reference), with the user being asked to give 
confirmation that he wishes the process to continue (and perhaps fiirther 
20 authentication of his association with the smart card - for example, by entering a 
password), the user smart card 1008 then being left in the smart card reader 1 107. 

The image data requested by the operating system of the client platform 1001 is then 
provided by the trasted server 1109 (step 1140), preferably by a secure 

25 communications channel or process (such as PPTP) to the protected memory 1009. 
Optionally, an image transfer log is made or updated (step 1145) - alternative 
approaches to creation and maintenance of image transfer logs are discussed fiirther 
below. Another optional step (step 1 150) is for an integrity check to be performed by 
the user smart card 1008 by checking a signature of the image data with the server 

30 trasted component public key, to verify whether this data is indeed from the expected 
source. 
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The image data received from the trusted server 1 109 is then displayed (step 1 155) on 
the display 1005 operating under control of the tmsted display processor functionality 
of the client trusted component 1003. At least a part of the image displayed is that 
stored within protected memory 1009 - other parts of the image displayed may, in 

5 appropriate arrangements, be from processes operating entirely within the client 
platform 1001. The user may now provide input to the client trusted platform 1001 
through the normal user interface, and this information is provided (as message 1010) 
to the trusted server 1109 (step 1160), again preferably using a secure 
communications channel. Execution of the data on the trusted server 1 109 is then 

10 modified, or alternative data selected, according to the user choice, resulting in the 
provision of modified image data by the trusted server 1109 (step 1165). The 
processes from steps 1145 to 1165 may then be repeated as often as necessary. A 
request to end the session may be made by the trusted server 1 109 (for example, when 
credit has been exhausted) or by the user (step 1170). Optionally, this may be 

15 followed by making or updating a usage log (alternative possibilities for such a log 
are discussed below) - an addition or an aUemative may be the making of a billing 
charge to the user (step 1 1 75). 

If the provision of image data is free or unlimited (if, for example, the purpose of 
20 using the trusted terminal arrangement is only to prevent release of executing code to 
individual users, or if the only "payment" required is the display of advertising 
provided by the trusted server), there may be no need to provide a usage log (or 
billing information). If a usage log is required, there are at least three options 
available for providing it. 

25 

A first option is for usage information to be stored on the trusted server 1 109. Usage 
can be logged by the trasted server 1 109 at the time of each image data transfer to the 
chent platform 1001. Billing information (such as a credit card or other account to 
which use can be billed) can be obtained from the user (by smart card or client trusted 
30 component, or from elsewhere) in the registration process, and also stored on the 
trusted server 1109. Preferably, all such information (particularly the user account 
information) is held within the server tmsted component 1 106. An alternative is for 
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the information to be held in other memory within the trusted server 1 109, but secured 
with a cryptographic key held within the server trusted component 1 106. 



A second option is for usage information to be stored on the cHent trusted platform 

5 1001, preferably within the client trusted component 1003 (or alternatively held in the 
protected memory 1009, or secured within the protected memory 1009 or other 
memory within the chent trusted platform 1001 secured by a cryptographic key held 
within the client tmsted component 1003). The tmsted server 1109 (preferably the 
server tmsted component 1 106) could then interrogate the client tmsted platform 1001 

10 as needed to find out usage information - alternatively, the client trusted platform 
1001 could report this to the tmsted server 1109 at predetermined times or intervals. 
One approach to this would be for the tmsted server 1109 to download an applet to 
the client tmsted platform 1001 to perform reporting back of usage or billing 
information, or to allow the tmsted server 1109 to determine what image data has 

15 already been displayed by that user. The tmsted server 1109 can act as a 
clearinghouse, with information relating to billing being sent back, via the 
downloaded software, to the client tmsted platform 1 106. Again, it is appropriate for 
payment to be made by providing user credit card details to the tmsted server 1 109 - 
these can be held within the client tmsted component 1003 (or provided by the user 

20 smart card 1008 via the client tmsted component 1003) and forwarded to the tmsted 
server 1 109 with usage information. 

The third option is for usage information to be stored on the user smart card 1008. 
This had the advantage of measuring use by a specific user, rather than a specific 

25 tmsted platform, and may therefore be particularly appropriate to a hotdesking 
environment (or one in which publicly available tmsted platforms are provided - as 
may be the case in libraries or airport lounges). Again, the tmsted server 1 109 could 
interrogate the smart card 1008 (via the client tmsted platform 1001) to find out usage 
or account information, or this information could be provided to the tmsted server 

30 1 109 at regular times or intervals, perhaps by downloading of an applet to the smart 
card 1008 as described for the second option above. 
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As indicated above, data usage may be significant for billing purposes as well as for 
checking data accessed by the user. One situation where this is relevant is where the 
user is allowed a specific number of accesses to the data (such as in fixed usage 
licensing models - licensing models appropriate for use for data executed in whole or 
in part on a tmsted computing platform are further discussed in the applicant's 
copending International Patent Application No. PCT/GB 00/03101 entitled 
"Computer Platforms and Their Methods of Operation" filed on 1 1 August 2000 and 
incorporated by reference herein) or is allowed only limited access for pre-purchase 
trial, hi such arrangements, it may be necessary for the tmsted server 1 109 to check 
the log file (wherever stored) relating to the relevant user or client platform to ensure 
that permitted use has not been or will not be exceeded. If there is evidence fi-om the 
log that use has been exceeded (perhaps that there has been a previous trial use of the 
software concerned), then the tmsted server 1109 will cause an error message to be 
generated and provided to the user on the client trusted platform 1001 (probably by 
means of the display 1005, indicating for example that multiple trials of the software 
are not permitted), and the relevant code (if appropriate) will not be executed on the 
tmsted server 1 109. This approach allows the full functionality of trial software to be 
employed by a user in a software trial without risk to the developer of unauthorised 
use. 



In such an arrangement, trial software may for example be provided to be available 
for a limited time of use on a trusted server 1 109, the limited time being set by the 
developer. The use of the tmsted terminal fimctionality of the client/server 
arrangement described above ensures that the user (operating the client) cannot copy 
the software or use it for longer than the allocated period, or contravene any other 
term of the agreement under which the software is licensed. It can be seen that this 
arrangement is particularly effective for software trials, but also provides a workable 
model of use where the developer does not even wish object code to be provided to 
users, but instead wishes to provide his code for users to access as a pay-per-use 
service. 



Another model possible is for a trial license to be converted to a fiiU license after a 
number of trial uses. In this case, when the user signs a license agreement, it is agreed 
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that his smart card (or client trusted component) will be provided with a log file 
(preferably securely held) that indicates that the trial software has been downloaded, 
and which can be updated by whatever mechanism is appropriate on software use and 
which can be accessed by the trusted server 1 109 when required. For example, before 

5 image data is sent to the client, the log file can be checked to see if or how often this 
trial has been used before, and a decision made by the server as to whether the trial 
can be continued - when the image data is sent, the log file is updated. After a certain 
time or number of uses, the user is prompted for payment for continued use of the 
software, or it may have been agreed as part of the trial agreement that payment be 

10 made if a certain number of uses is exceeded (in which case account information is 
provided then, or earlier, to the trusted server 1 109). 

As can be seen fi-om the above, arrangements according to the present invention can 
provide great value in allowing software to be trialled with fiill fiinctionality or 
15 provided on a metered basis, or for content to be provided on a trial or metered basis 
or accompanied with advertising content, without risk to the software developer or 
content provider of loss of economic value in their product. 
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CLAIMS 

1. A client platform adapted to provide restricted use of data provided by a 
5 server, the client platform comprising: 

a display; 

secure communications means: 

a memory containing image receiving code for receiving data from a 
server by the secure communication means and for display of such 
10 data; 

wherein the client platform is adapted such that the data received from a server 
is used for display of the data and not for an unauthorised purpose. 

2. A client platform as claimed in claim 1, wherein the client platform contains a 
15 client trusted component physically and logically protected from modification, 

wherein said client trusted component is adapted to prevent data received from 
a server from being used for an unauthorised purpose. 

3. A chent platform as claimed in claim 2, wherein the client trusted component 
20 contains an integrity monitor adapted to provide a measure of the integrity of 

code operating on the client platform, and the integrity monitor is adapted to 
monitor the integrity of the image receiving code. 

4. A client platform as claimed in claim 2, wherein the image receiving code is 
25 located within the client trusted component, 

5. A client platform as claimed in claim 2, wherein a display controller lies 
within said client trusted component, such that a display of the client platform 
is controlled from within the client trusted component. 



30 



6. A client platform as claimed in any of claims 2 to 5, wherein the client 
platform comprises a secure user interface for providing user input directly to 



10 
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the client trusted component, and wherein the image receiving code is adapted 
to provide user input received from the secure user interface to a server. 

7. A client platform as claimed in any of claims 2 to 6, wherein the client trusted 
component is adapted to authenticate other trusted components or secure 
tokens. 

8. A client platform as claimed in any of claims 2 to 7, wherein the client trusted 
component is adapted to determine a trusted status of other platforms, 

9. A client platform as claimed in any preceding claim, also comprising a smart 
card reader for receiving a smart card comprising a user's secure token. 



10. A chent platform as claimed in any preceding claim, wherein a part of the 
15 display is reserved for display of data determined by the server independent of 

any request by the client platform. 

11. A server adapted to provide data to a client platform for restricted use by the 
client platform, comprising: 

20 a memory containing image sending code for providing an image of 

data executed on the server; and 

secure communications means for secure communication of images of 
data to a client platform 
whereby the server is adapted to determine that a client platform is adapted to 
25 ensure restricted use of the data before it is sent by the image sending code. 

12. A server as claimed in claim 11, containing a server trusted component 
physically and logically protected from modification, and wherein the server 
component contains an integrity monitor adapted to provide a measure of the 

30 integrity of code operating on the client platform. 



13. 



A server as claimed in claim 12, wherein the server tmsted component is 
adapted to authenticate other tmsted components and secure tokens. 



wo 01/23980 




PCT/GBOO/03689 



44 



14. A system for providing image data securely to a user for restricted use, 
comprising: 

a client platform as claimed in any of claims 1 to 10; and 
5 a server as claimed in any of claims 11 to 13; 

wherein a user on the client platform requests image data from the server to 
view at the cUent platform. 



15. A system as claimed in claim 14, wherein a user requests execution of code on 
10 the client platform to provide image data to be viewed at the client platform, 

16. A system as claimed in claim 14, wherein a user requests execution of code, 
and wherein said code executes partly on the client platform and partly on the 
server to provide image data to be viewed at the client platform, wherein the 

15 image data is viewed at the client platform in association with the results of 

code executed on the client platform. 

17. A system as claimed in any of claims 14 to 16 where dependent on claim 9, 
further comprising a user smart card wherein the server is adapted to 

20 determine that the user smart card is such as to allow the image data to be sent 

to the client platform. 

18. A method of providing image data to a client platform for restricted use, 
comprising: 

25 a chent platform requesting image data from a server; 

the server determining that the client platform both has permission to 
receive image data, and is adapted to use the image data only for the 
restricted use; and 

provision of the image data over a secure conununication channel. 



30 



19. A method as claimed in claim 1 8, ftirther comprising provision of request data 
from the client platform to the server, and provision of modified image data 
based on the request data. 
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20. A method as claimed in claim 19, wherein the provision of request data and 
the provision of modified image data are repeated as often as required. 

5 21 . A method as claimed in any of claims 1 8 to 20, further comprising updating of 
a usage log after image data or modified image data is provided to the client 
platform. 

22. A method as claimed in any of claims 18 to 21, wherein the step of 
10 determining permission comprises determining whether a smart card 

containing a user pemiission is in session with the client platform. 

23. A method as claimed in any of claims 18 to 22, wherein a part of the image 
data is determined by the server independent of any request from the chent 

15 platform. 



24. 



A method as claimed in claim 23, wherein said part of the imaging data 
comprises advertising content. 
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